性能测试关注的 Oracle 指标
作者：杨建旭，在自动化测试、性能测试方面有深入的研究，现任中国人民银行清算总中心性能测试团队负责人，高级技术经理。
社区专栏：系统性能测试 http://www.talkwithtrend.com/home/space.php?p=blog&uid=898849
数据库的性能优化是个非常复杂的事情，熟悉Oracle的专家能手更是数不胜数，所以写了数十篇文章都没敢写过Oracle。直到最近，单位请来了Oracle原厂培训，请Oracle大师来给新入职的同学做培训，作为张罗这事的参与者之一，笔者也跟着听了一天，竟然发现大师有几个地方讲错了，主要是在理论联系实际的问题分析、AWR报告解读方面，提问之后竟然把大师挂在了台上。后来想想，大师也有不懂的，我怕什么呢，写！从性能测试的角度看Oracle，我们换个视角。
一个业务的响应时间受到这个业务所以环节性能的影响，如果被测系统涉及到数据库，则需要对数据库指标进行监控。这里的数据库指标并不是服务器本身的CPU、内存、IO等指标（当然，这些指标也是要监控的），而是指从数据库角度来看的指标，例如Buffer命中率、SQL执行时间等，本文介绍Oracle数据库的指标。
数据库的指标千千万，一般来说，会重点关注一些指标，这里就介绍一下作为测试人员需要关注的指标。
关注指标之前，需要做的是关注Oracle系统的告警（例如：表空间满了）。只有告警消除后，各类指标才是正常状态下的指标。
查看Oracle性能指标的方法有不少，本文主要以AWR报告为目标做介绍。自动工作量存储（Automatic Workload Repository AWR）是随着数据库一起被安装的，它不仅能收集统计数据，还能从统计数据中分析出度量数据，后续会详细介绍AWR，本文主要介绍指标本身的概念。
SQL语句执行时间、吞吐量
数据库的用户是应用，应用使用数据库来执行SQL语句。SQL语句的执行时间最能反映满意用户需要的能力。当一个应用处理速度比较慢的时候，自然会查看数据库的SQL执行时间。
一个数据库有千千万个指标，其他指标即使异常到令人发指，只要用户满意，往往也没有人去刻意做调优。
执行时间：
在AWR>Main Report>SQL Statistics目录下，可以看到如下SQL语句执行时间的分目录。
如果应用程序比较慢，并且比较怀疑是数据库的原因，那么关注一下排在前几位的SQL语句。作为初次观察，关注SQL ordered by Elapsed Time，这个指标是按照整个SQL的执行时间来排序的，以下图为例：
这里有SQL语句的名称、执行次数（Executions）和每次的执行时间（Elapsed Time per Exec(s)）。如果这个执行时间比预想的要长，那么需要查看一下这个语句的执行计划。
吞吐量：
执行次数除以总时间（两个AWR快照之间的时间）就是这条SQL的吞吐量，吞吐量同样是比较重要的指标。SQL吞吐量无法根据业务压力而增长说明单条SQL的执行效率有问题或者系统的并发有问题（应用、中间件、数据库等环节均可能有并发的问题）
另外，%Total、%CPU、%IO这些指标一定要注意这个分目录的具体解释，因为每个分目录下的解释不一定一样，并且，这些指标可能和你大脑中想象的含义也不一样。
我看了解释以后发现和我的第一想象是不一样的。在看指标的时候，千万不要根据自己的猜测、经验来看，一定要查阅各个系统、各个产品自身对该指标的定义。
这里再多说几句，我们个人会对Oracle的一些指标有误解，那么Oracle作为一个产品也会对其他产品有误解。例如，AWR报告的开头部分：
这一段是Oracle对自身所处的系统环境信息做一个抓取，系统共18个核，72个逻辑CPU，但这个系统不一定有18个核的能力，还得具体查看环境是不是虚拟化平台，如果是，那么这18个核是虚拟的核，而真正能得到的CPU能力可能小于18。
Top等待
如果觉得数据库有性能问题，那么最先查看的就是Top等待事件。
看看哪个事件的Total Wait Time最大，就重点解决哪个事件。DB CPU如果最大一般是正常的，需继续关注DB CPU之外的事件。
等待事件五花八门，遇到没见过的可以网上查查，但看懂网上查来的结果也是需要些数据库的知识了，此处不是一朝一夕的花架子。
举一个性能测试中常见的例子，测试环境或者是刚刚搭建的生产环境常常是Oracle的默认参数，没有经过调整，log switch占到了Top等待事件的前面。
日志切换（Log switch）为什么等待时间这么多呢？首先就要了解日志、日志组是干什么，日志为什么要切换，什么情况下切不过去。
Redo日志组假如初始是2个日志，每个日志10M大小，分别记为A和B。当A写满的时候，就要switch到B去写日志，这时候就发生了日志切换。此时，可能1）如果开启了日志归档，需要将A写到归档日志里面。如果B这时候也写满了，就要再次switch回A。如果A还没有归档完成，那么就需要切换等待。可能2）A里面的内容还没有完成提交，B也不能把A的日志冲掉，此时产生了切换等待。
了解清楚之后，在不改变应用程序的情况下，可以通过增加单个日志大小（减少切换次数）、增加日志组个数（减少切换时可能的等待）来解决。比如日志大小从10M改为1G，日志从2个改为4个。
Instance Efficiency Percentages
这个分类下面大部分是Buffer命中率。命中率在数据库中是至关重要的，命中率的高低直接影响了数据库的性能。
介绍几个经常关注的指标
Buffer Nowait >99
在缓冲区中获取buffer 的未等待比率, 一旦此数据较低说明数据库存在大量出现buffer busy waits。
Buffer Hit >95
数据块在数据缓冲区中的命中率，通常应该在95%以上，否则考虑加大db_cache_size。当然，命中率低也不一定是cache小，也可能SQL写的烂、执行计划不当等原因。
Library Hit >95
代表着SQL在共享区的命中率，通常在95%以上。
当你发出一条SQL语句交付Oracle，在执行和获取结果前，Oracle对此SQL将进行几个步骤的处理过程，语法检查、语义检查、对sql语句进行解析、执行SQL返回结果。其中SQL解析的过程生成解析树(parse tree)及执行计划(execution plan)。这个过程是非常消耗CPU资源的，因此Oracle将解析好的SQL语句（或者说是执行计划）放在library cache中等待复用。
较低的库缓冲区的命中率意味着SQL语句被过早的推出了缓冲区（又要再次硬解析），加大共享池。
Redo Nowait >99
写日志的不等待比率,太低可能是log_buffer偏小，或者log_buffer向磁盘刷日志的参数 _log_io_size(默认为1/3*log_buffer/log_block_size,设置_log_io_size 为合适的值，比如适当减小)，或者存放日志的磁盘性能不好（比如RAID划分不当，RAID5或6改为RAID10），或者日志组个数偏少、每个redo log大小偏小，导致log buffer的数据不能及时进入磁盘。
In Memory Sort >95
值过低表明很多排序都在TEMP表（磁盘）中进行，需要检查是否有效率过低的SQL，分析sort_area_size是否太小。也有可能是SQL太烂，需要优化SQL，技术上优化不了了就改为优化业务流程。
Soft Parse >95
能够复用现有执行计划就是软解析，不能复用就要重新硬解析。
近似当作SQL在共享区的命中率，通常高，代表使用了绑定变量, 如果低于80％意味着大量硬解析，SQL没有被有效的重用，需要调整应用使用绑定变量，或者设置cursor sharing参数。
内存使用情况
数据库的内存大小对性能的影响往往比CPU的多少还要重要。
因此需要关注操作系统分给Oracle多少内存（memory target），以及Oracle内部各个内存区域的使用情况。
尽管Oracle11g之后内存默认是自动管理的，但我们了解内存自动变化的情况，对性能分析也有帮助，另外有些用户还是习惯用采用手工方式进行内存区域的划分，划分的是否合理，也可以从内存使用的情况来检查。
假如内存采用了默认的自动管理方式，我们关注的不仅仅是大小，还有在测试过程中的变化趋势。所有的项目都有Begin时的大小和End时的大小，关注其变化趋势。
如果某个区域有明显变大的趋势，说明对这个区域的需求量比较大，而初始的值比较小，Oracle在运行过程中慢慢的调整它。
但Oracle的调整并不是实时的，也不一定能把各个内存区域的配比调到性能最优状态（况且还会有Oracle自身的bug）。
内存advisory
内存的advisory也是值得一看的。可以从中看看目前的内存够不够用。毕竟一个项目上线之前，谁都不知道它会吃多少内存，或者吃某个区域多少内存，测试环境可能内存还是打折的，遇到性能缓慢是不是由内存不足引起的呢？
关注Main Report>Advisory Statistics，可以看到好多区域的advisory
以SGA为例
可以看到SGA设置为多少M的情况下，对应的DB Time是多少，物理读是多少。由此可以初步判断当前的内存设置是不是合理。
相关文章：
如何规划和设计有效的系统性能测试场景？ | 本文包含50多个知识点
延伸阅读：性能测试工具的选取和设计
1、有哪些好的性能测试工具可用？
1） 测试工具常用的有：
Loadrunner：需license，但不少人是试用性质。功能、易用性方便最优秀，是性能工具的标杆
2） JMeter：无license，免费，是免费工具里面的标杆。易用性差一点。
3） 当然然还有很多其他工具，各有特色。还有些是专门测磁盘IO、网络IO的小程序。
2、用于模拟系统读写负载的测试工具？
在做主机及存储系统等综合测试（含高可用、性能）时，常会碰到无法一开始就带应用测试，但又需要模拟真实应用的读写场景。有哪些比较简单又实用的测试工具，用于模拟系统的读写及计算负载？
磁盘IO的压测工具：例如orion、iometer，dd命令、xdd、iorate，iozone，postmark
不同的工具支持的操作系统平台有所差异，各具特色。
有的工具可以模拟应用场景，比如orion是oracle出品，模拟Oracle数据库IO负载（采用与Oracle相同的IO软件栈）。即模拟oracle应用对文件或磁盘分区进行读写（可指定读写比例、io size，顺序or随机）这里就需要提前知道自己的IO模型。如果不知道，可以采用自动模式，让orion自动的跑一遍，可以得出不同进程的并发读写下，最高的IOPS、MBPS，以及对应的响应时间。
比对dd，仅仅是对文件进行读写，没有模拟应用、业务、场景的效果。
postmark可以实现文件读写、创建、删除这样的操作。适合小文件应用场景的测试。
3、性能指标采集工具
由于性能指标包含很多方面
1）系统资源的指标（CPU、内存、网络IO、磁盘IO）
2）服务指标（响应时间、吞吐量）
3）业务指标（业务量、并发用户数、业务类型）
因此没有一个现成的工具可以抓取所有指标，原因是，一些指标是和业务、应用关联，需要用户自己定制。比如某个业务的响应时间，需要从日志采集，那就需要自己定制日志采集和统计的工具。
当然，这些工具也可以集成在一起
N台压力机没有跑出来N倍的效果
1）检查你发送压力的代码，有没有lock。具体来说，举个例子，所有的交易要有全局唯一的交易编号。如果所有的压力机上的交易标号是由一台机器产生的，这台机器产生编号的速度就是整个压力机集群的瓶颈。
2）检查是否有资源共用。比如所有压力机都是虚拟机，共用存储、CPU等等。比如所有压力机去某个数据库读数据。这个可以看压力机的资源利用情况、响应时间就可以看出来
3）可能是被测系统已经到瓶颈了，压力机能力再强，请求也发不出去了。
（杨建旭 分享）
更多相关主题文章请点击阅读原文
长按二维码关注公众号